Skip to content

Conversation

@steveej
Copy link

@steveej steveej commented Jun 23, 2017

Before these changes the Makefile makes the assumption of architecture targeted binaries for objcopy and strip. These are not available in my environment which is based on a custom nix-shell derivation.

I'm curious if this breaks in other environments :-)

steveej added 2 commits June 23, 2017 10:33
This is necessary on systems where the binaries don't contain the
architecture names, which doesn't mean they don't support the required
architectures.
This is necessary on systems where clang is installed gcc and is also
preferred over gcc.
@hawkw
Copy link
Member

hawkw commented Jun 23, 2017

hmm, this builds successfully on Travis, so at least it works on one other linux env. it'll definitely break the makefile on my mac, though, where the system gcc tool chain is mach-o only.

hmm, as much as i hate the thought of it, this does seem like a job for Autoconf...

@steveej
Copy link
Author

steveej commented Jun 23, 2017

hmm, as much as i hate the thought of it, this does seem like a job for Autoconf...

I have zero experience with Autoconf and can't intuitively identify macros to find a compatible version of objcopy in PATH. First I wanted to find the toolchain for the x86-64 target, on my system objcopy is not included in these prefixed programs. It's installed with the binutils package and has no prefix.
My next approach would be to use something like compgen and find all "*objcopy" executables, iterate through them and choose one that supports the output target elf64-x86-64.

Do you have any pointers?

@hawkw
Copy link
Member

hawkw commented Jun 23, 2017

I have zero experience with Autoconf

Same, actually; that's part of why I'm so loath to start using it (well, that and an idealistic belief that "we should be able to build the kernel with a modern toolchain").

Do you have any pointers?

0xFFFF0000, 0xFFFF0010, 0xFFFF0020... 🙂

My current solution to this kind of problem is a bunch of flaky shell scripts which work around system inconsistencies mostly by symlinking things to have the names and/or locations the Makefile expects. Considered objectively, this is... probably a worse solution than just having a configure file, but it's a tool I'm more familiar with. I'm sure we could graft on a workaround for your environment...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants